There are many reasons to upgrade services in a distributed computing system. For example, a service may have bugs that are fixed in an update, security holes that are patched, new databases that are added, and so on. In conventional distributed computing systems, updating a service requires taking the service off line, updating it, and then bringing the updated service on line. This can pose a problem where a service is used frequently or is a critical service in a distributed computing system. In such an instance, it may be costly to take the service offline. Moreover, when a service is updated, the updated service is not always 100% backwards compatible with the original service that was updated. Therefore, clients of the service may no longer be able to use the service once it has become updated.
In some conventional distributed computing systems, an updated service is brought online in parallel to the original service. Clients of the original service are notified of the updated service when they attempt to use the original service. The original service is then removed from the distributed computing system after a specified period of time (generally one to two weeks), in the assumption that all clients will have been notified of the updated service. This method of updating a service requires that the original service be modified to provide the notification to the clients of the new service. Moreover, the original service is removed from operation based on an estimate that all users have begun using the updated service, rather than based on any empirical data.